process: add emitExperimentalWarning()#9042
Conversation
jasnell
left a comment
There was a problem hiding this comment.
Good start but can be better. Left a few comments.
lib/internal/process/warning.js
Outdated
There was a problem hiding this comment.
Would recommend a name like ExperimentalWarning
lib/internal/process/warning.js
Outdated
There was a problem hiding this comment.
Perhaps a notice such as:
super(`${feature} is an experimental feature. Implementation details may change.`);
lib/internal/process/warning.js
Outdated
There was a problem hiding this comment.
There's no reason to create a separate class for this, something like the following would work easily...
const msg = `${feature} is an experimental feature. ` +
'Implementation details may change.';
process.emitWarning(msg, 'ExperimentalWarning');4c7d7d1 to
2806e9e
Compare
cjihrig
left a comment
There was a problem hiding this comment.
LGTM, but we're going to be stuck supporting process._useInspector for a long time.
|
@cjihrig yea, i'll fix that. I don't want to pollute process anymore than we have to |
There was a problem hiding this comment.
Why use a child_process here?
The following should work fine...
process.on('warning', common.mustCall((warning) => {
assert.strictEqual(warning.name, 'ExperimentalWarning');
assert.strictEqual(warning.message, message);
}));
process.emitExperimentalWarning('new_feature');There are other existing tests that validate that warnings are printed to stderr appropriately.
There was a problem hiding this comment.
Even better:
common.expectWarning('ExperimentalWarning', message);
process.emitExperimentalWarning('new_feature');
process.emitExperimentalWarning('new_feature');(call it twice to make sure it is not emitted more than once)
There was a problem hiding this comment.
hm, even though warnings can be emitted more than once? I guess it could make sense to only emit the experimental warning for each feature once?
There was a problem hiding this comment.
Should only be once I think.
Fishrock123
left a comment
There was a problem hiding this comment.
The test exemplifies my first comment imo, the fact that a child process is necessary.
lib/internal/bootstrap_node.js
Outdated
There was a problem hiding this comment.
This should be after setupRawDebug() at minimum.
However, I think this probably needs to happen at the end of the first tick?
i.e. do we want user handlers to catch this?
There was a problem hiding this comment.
ah yea, good point
There was a problem hiding this comment.
So, process.emitWarning currently emits the warning using process.nextTick(). Will that be sufficient or does it need an additional setImmediate()?
lib/internal/process/warning.js
Outdated
There was a problem hiding this comment.
I think the wording should be improved... the exposed feature could change at any time.
This adds process.emitExperimentalWarning() which can used to communicate to our users that a feature they are using is experimental and can be changed/removed at any time. Ref: nodejs#9036
2806e9e to
a7365f9
Compare
c133999 to
83c7a88
Compare
|
New CI: https://ci.nodejs.org/job/node-test-pull-request/4580/ |
|
@evanlucas ... CI looks good. Want to get this landed? |
|
I don't think this ever addressed my comment? |
lib/internal/bootstrap_node.js
Outdated
There was a problem hiding this comment.
gets emitted before a listener can be attached
There was a problem hiding this comment.
even though the warning is emitted in a process.nextTick() (https://github.com/nodejs/node/blob/master/lib/internal/process/warning.js#L47)?
There was a problem hiding this comment.
Yes, in both the REPL and case like node foo.js, the warning is emitted before user code is invoked. Setting a pre-load module using -r allows the warning event to be listened for.
There was a problem hiding this comment.
ahhh ok, sorry about that. Will get that fixed this weekend. Thanks!
There was a problem hiding this comment.
to make sure it is only emitted once
Fishrock123
left a comment
There was a problem hiding this comment.
the emit timing on that one needs to be addressed
|
This is a good candidate for backporting to v4 and v6, what think you @nodejs/LTS? |
|
With exception to the DeprecationWarning pieces, yes I agree. process On Saturday, October 29, 2016, Rod Vagg notifications@github.com wrote:
|
|
Oh ya, I forgot for a moment that the whole api was missing in v4. Easier case to limit backporting this bit to v6 at this stage probably. |
This is currently an experimental feature, so we should make sure users are aware that it can be changed at any time. Ref: nodejs#9036
a7365f9 to
0322d54
Compare
|
@evanlucas ... still want to pursue this? |
|
Going to close for now. I may have time in the near future to do this or not, but someone else can pick up if they want :] |
|
Also, perhaps we could use a Symbol to make it less accessible since it seems like this is for internal use only? |
|
I'll throw this on my todo list to look into |
Checklist
make -j8 test(UNIX), orvcbuild test nosign(Windows) passesAffected core subsystem(s)
process, internal
Description of change
This adds process.emitExperimentalWarning() which can used to
communicate to our users that a feature they are using is experimental
and can be changed/removed at any time. There is also a commit included
to use this api whenever the inspector is used.
Ref: #9036